1. Technical Field
The present invention relates to software development in general, and in particular to software debuggers. Still more particularly, the present invention relates to a software debugger having a monitor for monitoring conditional statements within a software program.
2. Description of the Related Art
The process of eliminating errors during software development is commonly known as debugging. Debugging can be costly and time consuming, depending on the complexity of the software being developed. Accordingly, software tools, such as debuggers, have been developed for reducing debugging cycle time. Debuggers typically execute as self-contained processes for controlling an application program under study through operating system primitives designed for that purpose.
An application program usually includes data and functions that operate on those data. The data and functions are defined in a source file. A tool called a compiler reads the source file and produces an object file. The compiler typically works in conjunction with other tools, such as an assembler, a linker and an optimizer, to accomplish such task. The object file contains bits that can be loaded into a computer memory to be executed. After having been loaded into the computer memory, the bits are called a program image. The object file also contains a symbol table that maps some of the original source information, such as variable and function names, onto addresses, offsets, sizes, and other pertinent properties of the program image. Quite often, the symbol table is not made part of the program image itself, but remains in the object file where other programs, such as the debugger, can read and analyze it.
A debugger can be used to examine the program image of a program in its execution state. Because the debugger has access to the symbol table, it allows a programmer to interact with the target process in terms of the names found in the source file. By going to the symbol table and looking up the variable's address and type, the debugger obtains the information it needs to satisfy the request from the programmer.
A debugger is often used to intercept or monitor the execution of a software program. It is usually the case that either the debugger or the target program is in control, but not both. If the target program is running, the programmer can interact directly with the target program while the debugger lies dormant. If the debugger is running, the programmer has the attention of the debugger and the target program is usually stopped (i.e., its program counter advances no further). When the debugger is running, it is said to be in control; when the debugger causes the target program to begin (or resume) execution, the debugger relinquishes control. The debugger will regain control after the target program counter reaches a pre-determined address. The debugger can deposit a machine instruction at that address, designed to cause some trap or to cause an operating system service to be called when it is executed. By virtue of prior arrangements between the debugger and the operating system, two things happen when the target program reaches one of those instructions: 1) the execution of the target program is put aside or stopped, and 2) the debugger is notified of the event and re-gains control. The debugger is able to determine the location of the event by examining program image state information saved by the operating system. Such special instructions, or the loci of such instructions, are called breakpoints. Breakpoints are usually set at the direction of the programmer, who may want to know if and when execution reaches a certain point in an application program, and may further desire to examine certain state information after the breakpoint has been triggered.
When debugging an application program that includes complex conditional statements, such as many levels of nested IF statements, it is often very time-consuming to determine why a conditional branch is taken. Today, there are basically two approaches a debugger can take in dealing with IF statements. The first approach is to allow a user to only step once on the IF statement such that one step will take the user either past the IF statement or to an associated ELSE statement. With such an approach, when the conditional branch statement is taken off to a path different from what the user expected, the user must start the process of evaluating variables and examining boolean logic to determine what had happened. The second approach is to allow a user to step through every single statement associated with an IF statement. While the second approach does facilitate a user in understanding exactly why the IF statement branches one way or the other, it is tedious and time-consuming for the user to always have to step through each condition whenever an IF statement is encountered. In addition, the user would not benefit from such feature unless the user knew ahead of time that a particular IF statement is going to be triggered (or very likely to be triggered) in a manner different from what the user expected.
Consequently, it is desirable to provide an improved software debugger for monitoring conditional statements within a software program.